1. Field of the Invention
The present invention concerns computer systems in general, and a mechanism for extending the functionality of the System Management Mode (SMM) and other similar hidden execution modes of processors in particular.
2. Background Information
Since the 386SL processor was introduced by the Intel Corporation, SMM has been available on IA32 processors as an execution mode hidden to operating systems that executes code loaded by BIOS or firmware. SMM is a special-purpose operating mode provided for handling system-wide functions like power management, system hardware control, or proprietary OEM-designed code. The execution mode is deemed xe2x80x9chiddenxe2x80x9d because the operating system (OS) and software applications cannot see it, or even access it.
IA32 processors are enabled to enter SMM via activation of an SMI (System Management Interrupt) signal. A similar signal called the PMI (Processor Management Interrupt) signal that is roughly analogous to the SMI signal is used for Itanium(trademark)-class processors. For simplicity, both SMI and PMI signals are sometimes referred to as xMI signals herein. There is also an interrupt message type called xe2x80x9cSMIxe2x80x9d or xe2x80x9cPMIxe2x80x9d that use the APIC/XAPIC IA32 memory-mapped delivery mechanism or the IPF SAPIC delivery mechanism.
To date, most BIOS implementations that leverage the SMM capability of the foregoing Intel processors simply register a monolithic section of code that is created during the build of the BIOS to support a specific function or set of functions particular to systems that use the BIOS. This code comprises 16-bit assembly in IA32 and 64-bit assembly for Itanium processors. The monolithic code segments for these legacy implementations runs from beginning to completion in response to all xMI activations.
There is no provision in today""s systems for the registration or execution of third-party SMM code, thus allowing no extensibility to the SMM framework. Such extensibility is often desired. For example, if the functions provided by the SMM code provided by the original equipment manufacturer (OEM) or the BIOS vendor for a given platform is insufficient, a developer or value-added reseller (VAR) has to either license the existing code from the BIOS vendor or OEM and attempt to graft their own logic into their implementation of SMM code, or live with the insufficiency, since the present SMM framework does not provide an alternative way to modify or extend the functions provided by the monolithic code segment. In addition, today""s implementations on IA32 processors are restricted to the 16-bit mode of the processor, thus limiting the size of the code and the possible leveraging of 32-bit or 64-bit software engineering techniques. Also, in that SMM is often used for chipset work-arounds (e.g., CPU or chipset errata that produces an erroneous and/or unpredictable result due to a design or manufacturing flaw in the chipset or CPU), the ability to get this key software update is gated by the monolithic BIOS implementation of the BIOS vendor or OEM.
In today""s environment, most chipset vendors opt for having the operating system vendor integrate such work-arounds using an OS-driver. In general, BIOS updates for SMM functions are problematic to effect and since the OS already has a hardware extensibility mechanism via its own driver model, BIOS vendors and OEMs are less motivated to provide these types of BIOS updates.